“用戶故事與用例是一回事嗎？” 人們經常會問這個問題，關於敏捷團隊是否應該練習使用故事與使用案例的糾紛已經存在多年。用戶故事和用例是一樣的嗎？如果沒有，哪個更好？你應該使用哪一個？或者可以同時使用？
雖然用戶故事和用例之間存在一些相似之處，但用戶故事和用例不可互換 ; 用戶故事和用例都標識用戶，他們都描述目標，但它們用於不同的目的。
用戶故事以您描述的事物的結果和好處為中心，而用例可以更精細，並描述您的系統將如何行動。敏捷中的用例是否存在，或者它們是否可以相互結合使用？
本文將告訴您用戶故事和用例之間的區別。
用戶故事通常以與用例相同的方式開始，因為每個用例都描述了一種使用系統的方式，以目標為中心，從用戶的角度編寫，使用業務的自然語言，以及 - 擁有 - 不講述整個故事。
如果我們考慮兩種方法中的關鍵組成部分：
用戶故事是一個註釋，用於捕獲用戶在工作中所做或需要做的事情。每個用戶故事都包含一個用戶自然語言編寫的簡短描述。與傳統的需求捕獲不同，User Story側重於用戶需要的內容而不是系統應該提供的內容。這為進一步討論解決方案和系統的結果留下了空間，該系統可以真正適應客戶的業務工作流程，解決他們的運營問題，最重要的是為組織增加價值。
3C是指良好用戶故事的三個關鍵方面。這個概念是由用戶故事實踐的共同發明人Ron Jeffries提出的。如今，當我們談論用戶故事時，我們通常指的是由這三個方面組成的用戶故事。
卡
用戶故事被寫為卡片。每個用戶故事卡都有一個簡短的句子，只有足夠的文字來提醒每個人這個故事的內容。
會話
通過整個軟件項目中客戶和開發團隊之間的持續對話，找到並重新定義需求。在利益相關者會議期間將發現並記錄重要的想法和決定。
確認
確認也稱為用戶故事的驗收標準。在討論需求時，客戶不僅告訴分析師他/她想要什麼，而且還確認在什麼條件和標準下工作軟件將被接受或拒絕。定義的案例寫成確認。請注意，確認的重點是驗證相應用戶素材的工作正確性。它不是集成測試。
20多年前由Ivar Jacobson介紹的用例在描述系統的功能要求時用於捕獲用戶（參與者）的觀點。它們描述了用戶使用軟件系統完成該目標的逐步過程。
用例描述了最終用戶想要“使用”系統的所有方式。用例捕獲用戶和系統可以交互的所有可能方式，從而實現用戶實現目標。它們還捕獲了阻止用戶實現目標的所有可能出錯的事情。
用例模型由許多模型元素組成。最重要的模型元素是：
用例規範是系統提供的功能的文本描述。它捕獲了演員 - 系統的互動。也就是說，它指定用戶如何與系統交互以及系統如何響應用戶操作。它通常以演員和系統之間的對話形式表達。用例規範在用例圖中用橢圓表示，是大多數人在聽到用例一詞時所想到的。
Alistair Cockburn解釋說，他（通過他諮詢的公司）看到了用戶故事的三個主要問題：
Visual Paradigm提供完整的敏捷環境，將用例，用戶故事，故事映射，關聯性評估和看板集成到一個完全無縫且自動化的端到端流程中。這個過程可以通過補充用例和故事映射工具來解決Alistair上面提到的用戶故事技術的缺點。其他有用的敏捷工具也可以滿足您更快，更好，更智能地管理敏捷項目的所有需求。
下面的概念圖概述了Visual Paradigm支持的敏捷工具。
第1點到第3點是補充用戶故事短缺的工具。第4點到第7點列出了其他用戶敏捷工具。
想要一個能夠很好地管理Scrum項目的敏捷工具嗎？Visual Paradigm具有用戶故事映射工具，Affinity Estimation工具，sprint管理工具和任務管理。
需要靈活的軟件解決方案來進行產品積壓管理嗎？Visual Paradigm支持強大的敏捷工具集，涵蓋用戶故事映射，親和力估計，衝刺管理等。它功能強大但易於使用，直觀且最重要的是AGILE。
warren2lynch
iThome鐵人賽
看影片追技術